Encrypt data of storage device

ABSTRACT

A request from a host is received requesting data from a storage device. Data of the storage device is written into a buffer of the host. The data at the buffer is to be encrypted and written back to the storage device. The requested data of the request is written to the buffer after the encrypted data is written back to the storage device.

CROSS REFERENCE TO RELATED APPLICATIONS

This is a continuation of U.S. application Ser. No. 13/870,820, filedApr. 25, 2013, which is hereby incorporated by reference.

BACKGROUND

Storage device controllers may receive data and encrypt the receiveddata before writing the encrypted data to a storage device. A hostseeking to write data to or read data from the storage device may send arequest to the storage device controller in order to access the storagedevice.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description references the drawings, wherein:

FIG. 1 is an example block diagram of a device to encrypt data of astorage device;

FIG. 2 is another example block diagram of a device to encrypt data of astorage device;

FIG. 3 is an example block diagram of a computing device includinginstructions for encrypting data of a storage device; and

FIG. 4 is an example flowchart of a method for encrypting data of astorage device.

DETAILED DESCRIPTION

Specific details are given in the following description to provide anunderstanding of examples of the present techniques. However, it will beunderstood that examples of the present techniques may be practicedwithout these specific details. For example, systems may be shown inblock diagrams in order not to obscure examples of the presenttechniques in unnecessary detail. In other instances, well-knownprocesses, structures and techniques may be shown without unnecessarydetail in order to avoid obscuring the examples of the presenttechniques.

Some types of storage device controllers may only encrypt data beingreceived, such as data crossing a Peripheral Component interconnectExpress (PCIE) boundary as it is transferred from a host's memory to thestorage device controller. Upon encrypting the received data, thestorage device controller may then write the encrypted data to a storagedevice. Thus, while any new data to be written to the storage device maybe encrypted by the storage device controller, old or existing data onthe storage device may not be encrypted by the storage devicecontroller. Moreover, modifying or adding hardware of the storage devicecontroller so that the storage device controller can directly encryptdata of the storage device may prove difficult and/or cost prohibitive.

Examples of the present techniques may dynamically borrow the host'sbuffer to store plaintext data of the storage device and then write backthe plaintext data from the buffer to the storage device in encryptedform. For example, in an example, a device may include an interfaceunit, a transfer unit and an encryption unit. The interface unit mayreceive a request from a host requesting data from a storage device. Thetransfer unit may write plaintext data of the storage device into abuffer of the host, in response to the request. The encryption unit mayencrypt the plaintext data and write the encrypted data back to thestorage device. Then, the interface unit may write the requested data ofthe request to the buffer after the encrypted data is written back tothe storage device. Thus, examples may allow for existing data of thestorage device to be encrypted by a storage device controller that islimited to encrypting only data to be written to the storage device, ata low cost and/or latency.

Referring now to the drawings, FIG. 1 is an example block diagram of adevice 100 to encrypt data of a storage device 150. The device 100 maycouple to or be included in any type of computing device or controllerthat interfaces with a memory, such as a secure microprocessor, astorage device controller, a notebook computer, a desktop computer, anall-in-one system, a server, a network device, a wireless device and thelike. In the example of FIG. 1, device 100 interfaces with a host 140and the storage device 150. For example, the device 100 may communicatewith the storage device 150 via a Serial Attached SCSI (SAS) connectionand may communicate with the host 140 via a Peripheral ComponentInterconnect (PCI) connection, Ethernet or IP protocol connection.

The host 140 may refer to any type of device that seeks to access thestorage device 150, such as a main processor of a computer or a computerconnected to a computer network. The storage device 150 may be anyelectronic, magnetic, optical, or other physical storage device thatstores data, such as a hard disk drive (HDD), solid-state drive (SSD)and the like. For example the storage device 150 may include one or morephysical drives (not shown) and one or more logical data volumesspanning one or more of the drives.

In FIG. 1, the device 100 is shown to include an interface unit 110, atransfer unit 120 and an encryption unit 130. The interface, transferand encryption units 110, 120 and 130 may include, for example, ahardware device including electronic circuitry for implementing thefunctionality described below, such as control logic and/or memory. Inaddition or as an alternative, the interface, transfer and encryptionunits 110, 120 and 130 may be implemented as a series of instructionsencoded on a machine-readable storage medium and executable by aprocessor.

The interface unit 110 may receive a request from the host 140requesting data from a storage device 150. The request may be a readtype request, a sense type request or any other type of request relatedto a transfer of data from the storage device 150 to the host 140. Theread request may relate to accessing data at a location of the storagedevice 150 indicated by the read request. The location may include oneor more addresses of the storage device 150. The sense request mayrelate to accessing sense data at a location of the storage device 150indicated by the sense request. The sense data may include status/errorinformation related to the data and indicate a success/normal condition,simple problems such as no disk being loaded, serious hardware failures,and the like. For example, the device 100 may transfer the data and/orsense data thereof from the storage device 150 to the buffer 142 inresponse to the read or sense type request of the host 140.

The transfer unit 120 may write plaintext data of the storage device 150into a buffer 142 of the host 140, in response to the request. The termplaintext may refer to an unaltered representation of data before anyaction has been taken to conceal, compress, or modify it in anothermanner. The term plaintext does not necessarily refer to text nor datathat is plain.

An amount of the plaintext data written to the buffer 142 may be basedon a size allocated for the buffer 142 by the host 140 for the requesteddata. For example, if the host 140 requested to read 512 bytes or ablock of data of the storage device 150 via the read request, then thehost 140 may have allocated the buffer 142 to be 512 bytes or a blocklong. Further, the host 140 may have a plurality of buffers allocatedbased on a plurality of outstanding requests to the storage device 150.

However, the plaintext data written to the buffer 142 by the transferunit 120 may not be the data requested by the host 140 via the request.Instead, the plaintext data may simply be data which the device 200seeks to write back to the storage device 150 in encrypted form. Thus,the transfer unit 120 may, for example, read plaintext from the storagedevice 150 that the device 100 seeks to encrypt, in response to therequest, such as the read or sense type request. For example, in FIG. 1the plaintext data is shown to be read from a first location 152 that isdifferent from a second location 154 where the actual requested data isstored in the storage device 150.

In one embodiment, the plaintext data may be read sequentially oriteratively from a disc of a storage volume (not shown) of the storagedevice 150. As the host 140 may only allocate the buffer 142 when thehost 140 expects to receive data in response to the request, the host140 may not allocate the buffer 142 when sending a write request. Thus,the device 100 may not send the plaintext data to the host 140 for thewrite request. Nonetheless, the device 100 may still process the writerequest by writing data from the host 140 to the storage device 150.

The encryption unit 130 may encrypt the plaintext data and may write theencrypted data back to the storage device 150. As shown in FIG. 1, forexample, the encryption unit 130 may receive the plaintext data from thebuffer 142 via the interface unit 110, encrypt the plaintext data, andthen output the encrypted data to the storage device 150

Encryption may refer to a process of encoding data in such a way thatunauthorized parties may not decipher the data while authorized partiesmay decipher the data. In an encryption scheme, the plaintext may beencrypted using a cryptographic algorithm, turning it into an unreadableciphertext. This is usually done with the use of an encryption key,which specifies how the message is to be encoded. For instance, the keymay be a piece of information or parameter that determines a functionaloutput of a cryptographic algorithm. The cryptographic algorithm may bea symmetric or asymmetric key algorithm. Examples of symmetricalgorithms include Twofish, Serpent, AES (Rijndael), Blowfish, CAST5,Rivest Cipher 4 (RC4), Triple Data Encryption Algorithm (3DES),International Data Encryption Algorithm (IDEA) and the like. Examples ofasymmetric algorithms include Diffie-Hellman key exchange protocol,Digital Signature Standard (DSS), ElGamal, Paillier cryptosystem, RSAencryption algorithm and Cramer-Shoup cryptosystem, and the like. Thesealgorithms may include a procedure for performing encryption ordecryption.

As shown in FIG. 1, the encrypted data may be written to the same firstlocation 152 as the plaintext data from which the encrypted data wasderived. Thus, by allowing the plaintext data to be overwritten with theencrypted data, the plaintext data may effectively become encrypted. Theinterface unit 110 may write the requested data of the request to thebuffer 142 after the encrypted data is written back to the storagedevice 150. This way, the encrypted data may be not lost before it canbe written back to the storage device 150. After the requested data iswritten to the buffer 142, the request may be considered completed.

The encryption unit 130 is located at the device 100, and not the host140 or the storage device 150. Further, the encryption unit 130 may onlybe able to encrypt data received externally via the interface unit 110.The host 140 may only be connected to the storage device 150 via thedevice 100. Thus, the device 100 may encrypt the plaintext data afterreading the plaintext data from the buffer 142 of the host 140 andbefore writing the plaintext data to the storage device 150.

FIG. 2 is another example block diagram of a device 200 to encrypt dataof a storage device. The device 200 may couple to or be included in anytype of computing device or controller that interfaces with a memory,such as a secure microprocessor, a storage device controller, a notebookcomputer, a desktop computer, an all-in-one system, a server, a networkdevice, a wireless device and the like.

The device 200 of FIG. 2 may include at least the functionality and/orhardware of the device 100 of FIG. 1. For example, the device 200 ofFIG. 2 includes the interface unit 110 and the encryption unit 130 ofthe device 200 of FIG. 1. A transfer unit 220 included in the device 200may have at least the functionality and/or hardware of the transfer unit120 of FIG. 1. The device 200 further includes a determination unit 130.Similar to FIG. 1, the device 200 also interfaces with the host 140 andthe storage device 150.

The determination unit 210 may include, for example, a hardware deviceincluding electronic circuitry for implementing the functionalitydescribed below, such as control logic and/or memory. In addition or asan alternative, the determination unit 210 may be implemented as aseries of instructions encoded on a machine-readable storage medium andexecutable by a processor. The determination unit 210 may determinewhich of the requests received by the interface unit 110 include the atleast one of read and sense type request and forward this determinationto the transfer unit 220. The transfer unit 220 may carry out the aboveoperations described in FIG. 1, if the request is the read or sense typerequest.

Here, the transfer unit 220 may further store a progress 222 of theencrypted data written back to the storage device 150 at a non-volatilememory (not shown). For example, the progress 222 may be a percentagenumber indicating what percent of the storage device 150 or a volumethereof is encrypted or remains to be encrypted. Alternatively oradditionally, the progress 222 may be a log recording each logical blockaddress (LBA) after the encrypted data has been written to that LBA.

The transfer unit 220 may reference the stored progress 222, forinstance, if a power failure occurs at the device 200 before all of theencrypted data at the buffer 142 is written back to the storage device150. In this case, the device 200 may be also to resume transferring theencrypted data from the buffer 142 to the storage device 150 from acurrent point at which the device 200 previously stopped. Thus, thedevice 200 may be able to reduce or prevent redundant encryption ofplaintext data and/or redundant transfer of encrypted data.

The transfer unit 220 may send a complete message after the requesteddata is written to the buffer 154, to indicate to the host 140 that therequest has been completed. The host 140 may then be free to reallocatethe buffer 142 and/or overwrite the buffer 142 after the completemessage is received. The complete message may be sent from the transferunit 220 to the host 140 via the interface unit 110.

FIG. 3 is an example block diagram of a computing device 300 includinginstructions for encrypting data of a storage device. In the embodimentof FIG. 3, the computing device 300 includes a processor 310 and amachine-readable storage medium 320. The machine-readable storage medium320 further includes instructions 321, 323, 325, 327 and 329 forencrypting the data of the storage device.

The computing device 300 may be, for example, a secure microprocessor, anotebook computer, a desktop computer, an all-in-one system, a server, anetwork device, a wireless device, or any other type of user devicecapable of executing the instructions 321, 323, 325, 327 and 329. Incertain examples, the computing device 300 may include or be connectedto additional components such as memories, sensors, displays, etc.

The processor 310 may be, at least one central processing unit (CPU), atleast one semiconductor-based microprocessor, other hardware devicessuitable for retrieval and execution of instructions stored in themachine-readable storage medium 320, or combinations thereof. Theprocessor 310 may fetch, decode, and execute instructions 321, 323, 325,327 and 329 to implement encrypting the data of the storage device. Asan alternative or in addition to retrieving and executing instructions,the processor 310 may include at least one integrated circuit (IC),other control logic, other electronic circuits, or combinations thereofthat include a number of electronic components for performing thefunctionality of instructions 321, 323, 325, 327 and 329.

The machine-readable storage medium 320 may be any electronic, magnetic,optical, or other physical storage device that contains or storesexecutable instructions. Thus, the machine-readable storage medium 320may be, for example, Random Access Memory (RAM), an ElectricallyErasable Programmable Read-Only Memory (EEPROM), a storage drive, aCompact Disc Read Only Memory (CD-ROM), and the like. As such, themachine-readable storage medium 320 can be non-transitory. As describedin detail below, machine-readable storage medium 320 may be encoded witha series of executable instructions for encrypting the data of thestorage device.

Moreover, the instructions 321, 323, 325, 327 and 329 when executed by aprocessor (e.g., via one processing element or multiple processingelements of the processor) can cause the processor to perform processes,such as, the process of FIG. 4. For example, the receive instructions321 may be executed by the processor 310 to receive a request from ahost (not shown). The determine instructions 323 may be executed by theprocessor 310 to determine if the request is related to requesting firstdata from a storage device (not shown). The write second datainstructions 325 may be executed by the processor 310 to write seconddata of the storage device to a buffer (not shown) of the host based onthe determination.

The encrypt instructions 327 may be executed by the processor 310encrypt and write the second data back from the buffer to the storagedevice after the second data is transmitted. The write first datainstructions 329 may be executed by the processor 310 write the firstdata to the buffer after the encrypted data is written back to thestorage device. The second data may be read from the buffer before thesecond data is encrypted and written to the storage device. Further, thesecond data may be encrypted at the device 300.

FIG. 4 is an example flowchart of a method 400 for encrypting data of astorage device. Although execution of the method 400 is described belowwith reference to the device 200, other suitable components forexecution of the method 400 can be utilized, such as the device 100.Additionally, the components for executing the method 400 may be spreadamong multiple devices (e.g., a processing device in communication withinput and output devices). In certain scenarios, multiple devices actingin coordination can be considered a single device to perform the method400. The method 400 may be implemented in the form of executableinstructions stored on a machine-readable storage medium, such asstorage medium 320, and/or in the form of electronic circuitry.

At block 410, the device 200 determines if a request received from ahost 140 requests data of the storage device 150 to be sent to the host140, such as read and sense type requests. Next at block 420, if therequest does not request for data of the storage device 150 to be sentto the host 140, the method 400 flows back to block 410. However, therequest, such as a write request, is still processed by the device 200via a separate process (not shown).

Otherwise, if the request does request for data of the storage device150 to be sent to the host 140, the method 400 proceeds to block 430. Atblock 430, the device 200 writes first data of the storage device 150 toa buffer 142 of the host 140 associated with the request.

For example, the buffer 142 may be memory space allocated by the host140 for data to be returned from the storage device 150 in response tothe request. The first data may include iteratively read blocks ofplaintext data of a disk of a storage volume of the storage device 150.Then, at block 440, the device 200 reads the first data from the bufferafter the first data has been written to the buffer 142. Next, at block450, the device 200 encrypts and writes the read first data back to thestorage device 150. For example, the device 200 may overwrite the firstdata at the storage device 150 with the encrypted data.

Lastly, at block 460, the device 200 may write second data of thestorage device 150 to the buffer 142 after the encrypted data has beenwritten back to the storage device 150. The second data may beassociated with the requested data of the request while the first datamay not be associated with requested data of the request. The requestmay still be active or pending at the host 140 while the device 200 iswriting and reading the first data to and from the buffer 142. Therequest may be not active or completed at the host 140 after the seconddata is written to the buffer 142.

According to the foregoing, embodiments provide a method and/or devicefor dynamically borrowing the host's buffer to store plaintext data ofthe storage device and then writing back the plaintext data from thebuffer to the storage device in encrypted form. Thus, embodiments mayallow for existing data of the storage device to be encrypted by astorage device controller that is limited to encrypting only data to bewritten to the storage device, at a low cost and/or latency.

We claim:
 1. A computing device comprising: an interface to receive arequest from a host device requesting data from a storage device; atransfer device to, in response to the request, retrieve plaintext datafrom the storage device and to write the plaintext data retrieved fromthe storage device into a buffer of the host device; and an encryptorto, in response to the request, receive the plaintext buffer from thebuffer of the host device and to encrypt the received plaintext data,the encryptor to write the encrypted data to the storage device, theinterface to, in response to the writing of the encrypted data to thestorage device, respond to the request by writing requested data of therequest to the buffer of the host device.
 2. The computing device ofclaim 1, wherein the writing of the plaintext data into the buffer ofthe host device is part of a technique to dynamically borrow the bufferof the host device to store the plaintext data that is not the requesteddata of the request.
 3. The computing device of claim 1, wherein theplaintext data is not the requested data of the request.
 4. Thecomputing device of claim 1, wherein the transfer device is to: store aprogress of writing the encrypted data to the storage device at anon-volatile memory, and reference the stored progress in response to apower failure occurring at the computing device before all of theencrypted data is written to the storage device.
 5. The computing deviceof claim 1, wherein an amount of the plaintext data written to thebuffer is based on a size allocated for the buffer by the host devicefor the requested data of the request.
 6. The computing device of claim1, wherein the transfer device is to send a complete message after therequested data is written to the buffer, to indicate to the host devicethat the request is completed.
 7. The computing device of claim 1,wherein, the request relates to at least one of read and sense typerequests, and the request does not relate to a write type request. 8.The computing device of claim 1, wherein the transfer device is toretrieve the plaintext data at least one of sequentially and iterativelyfrom the storage device.
 9. The computing device of claim 1, wherein thecomputing device comprises a storage device controller.
 10. Thecomputing device of claim 1, wherein the computing device is tocommunicate with the storage device over a Serial Attached SCSIconnection, and to communicate with the host device over an InternetProtocol connection or a Peripheral Component Interconnect connection.11. A method comprising: receiving, by a computing device, a requestfrom a host device requesting data from a storage device; in response tothe request, retrieving, by the computing device, plaintext data fromthe storage device; writing, by the computing device, the plaintext dataretrieved from the storage device into a buffer of the host device; inresponse to the request, receiving, by the computing device, theplaintext buffer from the buffer of the host device and encrypting thereceived plaintext data; writing, by the computing device, the encrypteddata to the storage device; and in response to the writing of theencrypted data to the storage device, responding, by the computingdevice, to the request by writing requested data of the request to thebuffer of the host device.
 12. The method of claim 11, wherein thewriting of the plaintext data into the buffer of the host device is partof a technique to dynamically borrow the buffer of the host device tostore the plaintext data that is not the requested data of the request.13. The method of claim 11, wherein the plaintext data is not therequested data of the request.
 14. The method of claim 11, wherein: therequest is active while the plaintext data is being written to and readfrom the buffer, and the request is completed after the requested datais written to the buffer.
 15. The method of claim 11, wherein theplaintext data includes iteratively read blocks of the plaintext data ofa disk of a storage volume of the storage device.
 16. A non-transitorycomputer-readable storage medium storing instructions that, if executedby a processor of a computing device, cause the computing device to:receive a request from a host device requesting data from a storagedevice; in response to the request, retrieve plaintext data from thestorage device; write the plaintext data retrieved from the storagedevice into a buffer of the host device; in response to the request,receive the plaintext buffer from the buffer of the host device andencrypt the received plaintext data; write the encrypted data to thestorage device; and in response to the writing of the encrypted data tothe storage device, respond to the request by writing requested data ofthe request to the buffer of the host device.
 17. The non-transitorycomputer-readable storage medium of claim 16, wherein the writing of theplaintext data into the buffer of the host device is part of a techniqueto dynamically borrow the buffer of the host device to store theplaintext data that is not the requested data of the request.
 18. Thenon-transitory computer-readable storage medium of claim 16, wherein theplaintext data is not the requested data of the request.
 19. Thenon-transitory computer-readable storage medium of claim 16, wherein theinstructions upon execution cause the computing device to: store, at anon-volatile memory, a progress of writing the encrypted data to thestorage device; and reference the stored progress in response to a powerfailure occurring at the computing device before all of the encrypteddata is written to the storage device.